六大設計原則可以應用在各種程式語言的開發，覺得非常有用，心得記錄如下

• SRP：單一職責（Single Responsibility Principle）

對像不應該承擔太多職責，唯有專注，才能保證對象的高內聚。

單一職責原則還有利於對象的穩定；對象的職責總是要提供給其他對象調用，從而形成對象與對象的協作，由此產生依賴關係。對象的職責越少，則對象之間的依賴關係就越少，耦合度減弱，受其他對象的約束與牽制就越少，從而保證了系統的可擴展性。

例如，在媒體播放器中，可以在MediaPlayer類中定義一組與媒體播放相關的方法，如Open()、Play()、Stop()等。這些方法從職責的角度來講，是內聚的，完全符合單一職責原則中"專注於做一件事"的要求。如果需求發生擴充，需要我們提供上傳、下載媒體文件的功能。那麼在設計時，就應該定義一個新類如MediaTransfer，由它來承擔這一職責；而不是為了方便，草率地將其添加到MediaPlayer類中。

• OCP：開放封閉

開放是指對擴展開放，封閉是指不必對原有模塊進行修改。

個人認為要達到OCP，關鍵是抽象化，可以定義一個或多個介面或抽像類，規定所有具體類必須實現的方法作為抽象層，這個抽象預見了你的系統或模塊將來的擴展，因此在任何擴展情況下都不會改變。這就使得系統的抽象層不需要修改，從而滿足了OCP中對修改關閉的原則。但是由於有具體實現的類可以擴展來改變系統的行為，所以系統的設計是開放的，滿足了OCP中擴展的要求。

• LSP：Liskov替換

繼承的優點是大大提升了代碼的複用度，但是缺點也同樣明顯：增加了對象的耦合程度，破壞了程序的封裝性，導致程序的可移植性變差。

Liskov替換原則的目的是增強程式的健壯性，簡單的說，即父類出現的地方子類也可以出現，並且將父類用子類替換後，也不會產生任何問題。然而，需要注意的是里氏替換原則反過來使用是不行的，子類出現的地方，父類未必適用。

里氏替換原則為良好的繼承定義了一個規範

1. 子類必須完全實現父類的方法
2. 子類可以擁有自己的個性：有自己的方法和屬性，也可以重寫（Override）或重載（Overload）父類的方法
3. 覆蓋或實現父類方法時輸入參數可以被放大
4. 覆蓋或實現父類方法時輸出結果可以被縮小覆蓋或實現父類方法時輸出結果可以被縮小

• DIP：依賴反轉

  • 解除高階模組(Caller)與低階模組 (Callee)的耦合關係，使高階模組不再直接依賴低階模組
  • 模組間要依賴抽象，不要通過具體的實現類。依賴關係通過接口(抽象)進行編程，這就降低客戶與實現模塊間的耦合。(接口或抽像類不依賴於實現類，實現類依賴接口或抽像類面向接口編程OOD )包含三層含義
    • 高層模組不應依賴於低層模塊，兩者都應該依賴其抽象
    • 抽像不應該依賴細節
    • 細節應該依賴於抽象
  • 高層模組、低層模組
    • 低層模組：每個邏輯的實現都是原子邏輯組成，不可分割的原子邏輯就是低層模組。一般和具體的實現相關
    • 高層模組：原子模塊再組裝就是高層模塊，一般和業務邏輯相關
  • 何為反轉
    • 依賴正置：類間的依賴是實實在在的實現類間的依賴，面向實現
    • 依賴反轉：編程就是對現實世界事務進行抽象，然後根據系統設計產生對抽象的依賴，代替事物間的依賴

• ISP：介面隔離

  • 隔離定義
    • 客戶端不應該依賴他不需要的接口
    • 類間的依賴關係應當建立在最小的接口上

為依賴接口的類定制服務，只暴露給調用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為一個模組提供定制服務，才能建立最小的依賴關係。

提高內聚，減少對外交互。使接口用最少的方法去完成最多的事情。